139151USNP 



PATENT 



TITLE OF THE INVENTION 

Midticast Architecture for a Virtual Private Local Area Network Service 
In A Metro Ethernet Network 



CROSS-REFERENCES TO RELATED APPLICATIONS 
10001] Not Applicable. 

5 

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 
DEVELOPMENT 

[0002] Not Applicable. 

10 

BACKGROUND OF THE INVENTION 

[0003] The present embodiments relate to computer networks and are more 
particularly directed to a multicast architectiu'e for a virtual private local area network 
service in a metro Ethernet network. 

15 [0004] Ethernet networks have found favor in many applications in the networking 
industry for various reasons. For example, Ethernet is a widely used and cost effective 
mediiun, with numerous interfaces and capable of commvmications and various speeds 
up to the Gbps range. Ethernet networks may be used to form a Metro Ethernet Network 
("MEN"), which is generally a publicly accessible netyvork that provides a Metro domain, 

20 typically under the control of a single adminiistrator, such as an Internet Service Provider 
("ISF'). A MEN is tjrpically used to connect between an access network and a core 
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network. The access network tjrpically includes private or end users making connectivity 
to the network. The core network is used to connect to other Metro Ethernet Networks, 
and the core network provides primarily a packet switching function. 

[0005] A MEN typically consists of a niunber of Provider Edge ("PE") nodes that are 
5 statically identified and configured for communicating with one another prior to the 
commxmication of packet traffic. The static plan connects the nodes in a point-to-point 
manner, that is, each PE node is connected to another PE node in an emulated and bi- 
directional virtual circxiit manner, where each such connection is achieved by a Label 
Switched Path ("LSF'). An LSP is sometimes informally referred to as a link. Thus, each 
10 PE node may commimicate to, and receive packets from, an adjacent PE node. Further, 
along each LSP, between adjacent PE nodes, are often a number of Provider ("F') nodes. 
The P nodes maintain no state information and serve primarily a routing function and, 
thus, are imderstood not to disturb the point-to-point connection between the PE nodes of 
the MEN, which are more intelligent devices. A different number of P nodes may be 
15 connected in one commtmication direction between two adjacent PE nodes as compared 
to the reverse communication direction between those same two adjacent PE nodes. 
Lastiy, note that a PE node in the MEN is also often connected to one or more Customer 
Edge ("CE") nodes, where those CE nodes thereby represent the interface between the 
MEN and an adjacent access network. 

[0006] With the development of the MEN architecture, there have further evolved 
additional topologies associated with such a network. One example, that pertains to the 
preferred embodiments that are later described, is the virtual private local area network 
service ("VPLS"). A VPLS creates an emulated local area network ("LAN") segment for a 
given set of nodes in a MEN. The VPLS delivers an ISO layer 2 broadcast domain that is 
fully capable of learning and forwarding on Ettiemet MAC addresses that is closed to a 
given set of nodes, Thus, within the VPLS, packets may be broadcast to all nodes on the 
VPLS. As a broadcast medium, however, the present inventors have observed a potential 
drawback occurring with respect to multicast commimications. Specifically, consider a 
fully-meshed VPLS MEN. In such a network, each PE node is bi-directionally connected to 
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every otiier PE node in the VPLS MEN. As such, any PE node may commiinicate as a 
source directly along an LSP to any other PE node as a destination, where that destination 
PE node may respond along anotiier LSP (albeit flirough a different set of P nodes) in the 
reverse direction back to the source PE node. A single commimication between two PE 
5 nodes in one direction and in this manner is referred to in the art as a unicast 
commimication. Complexity arises, however, when a single PE node endeavors to 
commimicate a packet to more tiian one destination PE node; such a communication by 
way of contrast is referred to in the art as a multicast communication. In the present state 
of the art, multicasting in a VPLS MEN is achieved by sending packet traffic on multiple 

10 point-to-point interfaces between PE nodes that are already communicating imicast packet 
traffic. As such, if a particular LSP is particularly burdened by already-existing tmicast 
traffic, then that same LSP is further burdened by the additional multicast traffic that is 
then sought to commxmicate along the same LSP. This may be problematic as one or more 
LSPs canying delay-sensitive unicast traffic are then disturbed by the addition of the 

1 5 multicast traffic. Also, certain regions of the MEN may be congested while others are not. 

[0007] Given the preceding, the preferred embodiments are directed to providing an 
improved MEN VPLS that more efficiently accommodates both unicast and multicast 
traffic, as described below. 
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BRIEF SUMMARY OF THE INVENTION 

[0008] In the preferred embodiment, there is a centralized node for coupling into a 
computer network along which network traffic flows between a plurality of nodes in a 
form of packets. The centralized node is programmed to perform the step of identifying 
5 requirements of imicast packet traffic along the network, where the xmicast packet traffic 
identifies a first traffic configuration along the network: The centralized node is also 
programmed to perform ttie step of constructing a second traffic configuration along the 
network, differing from the first traffic configuration, wherein ttie second traffic 
configuration is for routing multicast packet traffic along the iietwork. 

1 0 [0009] Other aspects are also described and claimed. 
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BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 

[0010] Figure la illustrates a network system according to the preferred embodiment 
and with respect to the flow of unicast traffic. 

[0011] Figiu-e lb illustrates the network system of Figure la and according to the 
preferred embodiment with respect to the flow of multicast traffic. 



[0012] Figure 2 illustrates a partial structure of an Ethemet packet. 
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DETAILED DESCWnON OF THE INVENTION 

[0013] By way of ilixistration of one preferred inventive implementation. Figure la 
depicts a network system designated generally at 10. Network system 10, in the preferred 
embodiments, is a Metro Ethernet Network ("MEN'') that provides a virtual private local 
5 area network service ("VPLS"). System 10 as shown in Figure la illustrates such a 
network as is known in the art, where the illustration is included to introduce various 
concepts and conventions and also because it is further improved upon as detailed later in 
connection with additional figures. 

[0014] By way of example, system 10 includes five Provider Edge ("PE") nodes PEi, 

10 PE2, PE3, PE4, and PE5, where the choice of five is only as an illustration and one skilled in 
the art should appreciate that any number of such nodes may be included. Indeed, note 
that often a MEN wiU include considerably more than five PE nodes. Each PE node may 
be constructed as a processing device by one skilled in the art using various hardware, 
software, and programming so as to perform the functionality described in this docxmierit. 

15 Note that the illustrated PE nodes may represent a single group or multiple groups of 
nodes, where each group is associated with a certain type of multicast For example, 
consider the case of a large business with needs for video streaming data to different 
nodes in that business; in such a case, one group of the business may have a desire to 
receive video streaming related to human resoxirce issues, while another group of the 

20 business may have a desire to receive video streaining related to business financial 
matters, while still anotiier group may have a desire to receive video streaming related to 
marketing issues. Thus, in this case, each group is separately identifiable from the other, 
and in the preferred embodiment a different multicast routing configuration is established 
for each such group. Of course, it also should be recognized that a PE node may belong to 

25 more than one group, such as a user that desires access to all three types of issues 
indicated in the present example. In this case, therefore, such a user is associated with 
three different multicast routing configurations, as also appreciated in additional detail 
later. Further, as a MEN system, while not shown but as also mentioned earlier in the 
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Background Of The Invention section of this document it should be understood that 
between adjacent PE nodes there may be located a nxmiber of Provider ("F') nodes. 

[0015] In system 10, preferably the network is fully meshed, that is, each PE node PEx 
is cormected to every other PE node in the system, where each connection is by way of a 
5 respective Label Switched Path {"ISP") illustrated with an arrow. For sake of reference in 
tiiis document, the bi-directional connection between two nodes is by way of an LSP pair 
("LSPF') that includes one LSP for commimications in one direction from a first PE node 
to a second node and another LSP for commimications in the opposite direction, that is, 
from the second PE node to the first PE node. As an example, PE node PEi is cormected, 

10 via four respective LSPPs, to each of PE nodes PEz, PE3, PE4, and PE5. Also, for sake of 
convention, the label used for each LSPP in Figure la (and Figure lb) identifies the two PE 
nodes between which the LSPP is connected. For example, between PE nodes PEi and PE2 
is an LSPPi A2; as another example, between PE nodes PE3 and PE4 is an LSPP3A4. Also, for 
sake of convention, each LSP in an LSPP is designated as LSPyry, where jc is the source PE 

15 node and y is the destination PE node for a given LSP. To simplify Figure la (and Figure 
lb), only a few of these LSPs are so labeled in Figure la. Thus, by way of example, in 
LSPP1A2 between PE nodes PEi and PE2, PE node PEi may commtmicate to PE node PE2 
by LSPm and PE node PE2 may commtmicate to PE node PEibyLSPzn. According to the 
preferred embodiment, the various LSPs of system 10 in Figure la define the point-to- 

20 point interfaces along which unicast traffic is allowed to pass. Thus, for the fuUy-meshed 
configuration of system 10, any PE node in that system may commtmicate directiy to any 
other PE node, tiiat is, with that commimication not being required to pass through one or 
more intermediate PE nodes. For example, PE node PEi may communicate unicast 
packets to PE node PE2 along LSP1A2. Other examples are readily apparent from the 

25 illustrated LSPs in Figure la. 

[0016] Figure lb again illustrates system 10 of Figure la, but the illustration of Figure 
lb is intended to depict issues directed to certain inventive aspects and pertain to 
multicast commimications in system 10. Further, as appreciated through the remainder of 
this document, these aspects preferably are combined with the illustration of Figure la 
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whereby system 10 per Figure la routes unicast commxmications in a first overall routing 
configuration such as in a point-to-point manner in a ftilly-meshed configuration, whereas 
system 10 per Figure lb routes multicast communications in a second overall routing 
configuration that differs at least in part from the first overall configuration, and for sake 
5 of distinction the multicast LSPs are shown with illustrated with dashed arrows. Various 
details are provided later as to the development of the second, or multicast, configuration. 

[0017] Looking to system 10 illustrated by Figure lb and how it differs in a first 
respect from Figure la, note that PE node PEi as illustrated includes a block depicting a 
central manager CM. In the preferred embodiment, central manager CM is intended to be 

10 the overall function that develops the multicast communications configuration in system 
10. This function may be included in one of the PE nodes such as illustrated in Figure lb 
in PE node PEi, or alternatively a central manager CM may be a separate node ttiat is not 
one of the PE nodes in the network, In eitiier case, central manager CM represents a 
processing device with sufficient knowledge of the state of the network to which it is 

15 coupled so as to provide the remaining function described herein. The actual hardware, 
software, and programming to achieve such a device is readily ascertainable by one 
skilled in the art given the functional description in this dociunent 

[0018] Another difference of system 10 as illustrated in Figure lb versus Figure la is 
that Figure lb is intended to illustrate the second overall routing configuration, that is, the 

20 configuration that applies to midticast commtmications (as opposed to imicast 
communications that are routed according to the illustration of Figure la). Specifically, in 
the preferred embodiment, central manager CM develops the second overall routing 
configuration based on various considerations as detailed below. As also detailed later, 
the second routing configuration preferably is maintained by communication of a 

25 different routing table from central manager CM to each of the PE nodes of the applicable 
network, where thereafter each such PE node routes multicast packets according to its 
respective table. Before detailing these aspects, note that Figure lb illustrates an instance 
where the second overall routing configuration includes all of the LSPs of the first overall 
routing configuration shown in Figure la, with two exceptions. Specifically, in Figure lb. 
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LSPiA2 and LSP2A4 are not included in tiie second overall routing configuration due to 
issues relating to attributes of those LSPs as used in the first overall routing configuration 
of Figure la. For example, the excluded LSP1A2 and LSP2A4 may already be heavily loaded 
with vmicast traffic. To further demonstrate this aspect. Figure lb illustrates a circled "X" 
5 to depict that each of these LSPs are missing, and those X's are labeled Mia2 to indicate the 
missing LSP1A2 and M2A4 to indicate the missing LSP2A4/ respectively. Thus, in Figure lb, 
where a missing LSP exists, the PE nodes are prohibited from communicating multicast 
packets directly to one another, although those packets may be re-routed along any of the 
other LSPs illustrated in Figure lb, as will be further demonstrated later. 

10 [0019] In the preferred embodiment, the second overall routing configuration, which 
recall routes multicast communications, is constructed by central manager CM by first 
constructing a single Steiner tree, and thereafter by potentially making exceptions to the 
Steiner tree construction based on various constraints. Steiner trees are known in the art, 
as may be appreciated with reference to F.K. Hwang, D.S. Richards, and P. Winter, The 

15 Steiner Tree Problem, North-Holland, Amsterdam, 1992, which is hereby incorporated 
herein by reference. Ehiring the Steiner tree construction, central manager CM identifies 
the multicast traffic requirements of each PE node in the group of interest as well as the 
existing unicast traffic requirements. For example, in one case traffic for a group Gi may 
be required to be mtilticast to PE nodes PEa, PE3, and PE4, whereas traffic for a group G2 is 

20 required to be multicast to PE nodes PE3 and PEi. Furtiier, central manager CM also 
identifies any LSPs that are overloaded or carry delay sensitive traffic or the like; these 
LSPs are then excluded or otherwise taken into consideration in the optimized Steiner tree. 
Further, and by definition, in constructing a Steiner tree, if an LSP in one direction must be 
avoided, then the reverse direction LSP is also removed from consideration in the 

25 determination of the multicast Steiner tree because a Steiner tree cannot be built with any 
imidirectional commtmication paths. In other words, a coimection between two nodes in 
a Steiner tree requires bi-directionality and, hence requires both LSPs to form an LSPP. 
Looking to Figures la and lb, therefore, an example of this approach would occur where 
LSPPiA2/ or only one of the LSPs LSPm or LSPzn in LSPPiaz/ is heavily loaded with imicast 
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traffic; as a result, in Figure lb, the Steiner tree shown therein does not include LSPPiA2f as 
indicated by the circled X at Mia2. 

[0020] By way of further appreciation to the construction of a Steiner tree, as known 
in the art, such a tree minimizes a certain cost function for all the nodes that constitute the 

5 tree, so in the preferred embodiment this applies to the PE nodes of system 10. Further, 
the cost function may be selected from various considerations. As an example with 
respect to a inimmized cost function in the preferred embodiment, a Steiner tree may 
minimize the nimiber of hops. In this case, the tree wiU minimize the total physical 
bandwidth used, where physical bandwidth is defined as the ntunber of hops between PE 

10 nodes times the bandwidth required per each LSP path covered by a hop. Note, however, 
that each imidirectional LSP that forms the LSPP between two PE nodes may have a 
different "cost." Since no known heuristic exists to build a Steiner tree with a node-to- 
node cormection having different costs in each direction, the preferred embodiment when 
constructing an LSPP between these nodes optimizes the cost that is the maximum of the 

15 two diiFferent costs of the two LSPs that form the LSPP. Thus, for the example where cost 
is represented by physical bandwidth, then the larger physical bandwidth along one of the 
two LSPs that form an LSPP is used to construct the Steiner tree LSPP. 

[0021] From the preceding, in an ideal example, the preferred embodiment central 
manager CM constructs the second overall routing configuration with a single Steiner tree; 

20 however, the present inventors recognize that often constraints arise that prohibit this 
ideal scenario. In this case, the Steiner tree is modified based on the constraints. For 
example, it miay not be possible to construct one multicast Steiner tree, for all PE nodes in a 
desired group, to simultaneously accommodate multicast, traffic coming from all the 
sources within the group at the same time. In other words, there may be one or more PE 

25 nodes that have bandwidth requirements tiiat caimot be met by the resulting Steiner tree. 
According to the preferred embodiment, if a single multicast Steiner tree is not fully 
supportive of the group's demands, then the multicast Steiner tree is modified by 
supplementing its configuration with one or more source based trees for those PE nodes 
that fail to utilize the Steiner tree. Source based trees are also known in the art, as may be 
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appreciated with reference to S. Deering, D. Estrin, D. Farinacd, V. Jacobsen, C.G. liu, and 
L.Wei, The PIM architecture for wide-area multicast routing, IEEE/ ACM Transactions on 
Networking, 4(2):153-162, April 1996, which is hereby incorporated herein by reference. 
As its name suggests, a source based tree provides for a next hop indication of a received 

5 packet based on the source node of the packet. Thus, in the preferred embodiment, central 
manager CM also may supplement the Steiner tree by constructing a source based tree, 
using a minimimi heuristic, and using the remaining links that are not included in the 
Steiner tree and that have available bandwidth. The addition of a source based tree also 
may accommodate a single LSP that was eliminated as one of two LSPs in an LSPP during 

10 the Steiner tree construction; in other words, recall from above tiiat a Steiner tree requires 
bi-directionally and, thus, during the Steiner tree construction, if a single LSP is identified 
as to be excluded from multicast communications, then its paired other LSP is likewise 
excluded. However, when the preferred embodiment supplements the previously- 
constmcted Steiner tree with a source based tree to provide the ultimate second overall 

15 routing configuration, then singular LSPs may be included in that corrfiguration. Lastly, 
note that if bandwidth requirements are still unsatisfied once a single source based tree is 
constructed, then one or more additional source tress are further constructed by central 
manager CM imtil those requirement are met. 

[0022] The preferred embodiments thus recognize that in a given implementation 
20 there are trade-offs between the more optimal approach of a single Steiner tree 
construction for the midticast traffic versus supplementing that Steiner tree with one or 
more source based trees. In the former, less state information is required to be stored at 
each PE node, where tiiat inforaiation is then available to central manager CM so ttiat it 
may construct the Steiner tree. Further, as is known, the Steiner tree by definition 
25 provides a more optimal routing configuration than a source based tree. However, a 
source based tree accommodates constraints for which a known heuristic is not available 
with a Steiner tree. 

[0023] Once central manager CM develops the second overall routing configuration, 
which includes at least a Steiner tree and possibly one or more source based trees, that tree 
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information is communicated in relevant part to each PE node PE^r in system 10. In the 
preferred embodiment this routing information that describes the multicast tree is sent to 
each PE node in a group, or to the entire network 10, via one of any known ascertainable 
signaling mechanisms. More particularly, for each recipient PE node, central manager CM 
5 sends to the node a table that is specific to that PE node based on its cormectivity within 
the second routing configiuration and, thus, different from the tables sent to each of the 
other nodes by central manager CM. For sake of reference in this document, such a table 
is referred to as a mRoute table. Thus, the mRoute table is particularized to each specific 
PE node based on where that node is located within the multicast tree(s). More 
10 particularly, the mRoute table indicates the next hop for a packet received by the specific 
PE node. Thus, as now explored by way of example in connection with the following 
Table 1, assume that it represents the mRoute table transmitted by central maiiager CM to 
PEnodePEi. 



Qmujp (or Group/source) 


Next PE node 


Gi 


PES 


G2 


PE2. PE3 


G3 


None (final destination) 










Gi. PE2 


PE4 


Gi. PE3 


PE2 



Table 1 



15 [0024] Looking now to various matters demonstrated by the mRoute table of Table 1, 
for sake of illustration a dashed line is included after the first three routing entries. The 
entries above the dashed line in the mRoute table are intended to illtistrate those that were 
identified by central manager CM when constructing a Steiner tree, and the entries below 
the dashed line are intended to illustrate those that were identified by central manager 

20 CM when constructing one or more source based trees. Table 1 also demonstrates the 
information for a total of three different groups, indicated as Gi, G2, and G3. Consider now 
some multicasting routing examples according to the preferred embodiment and in 
response to the mRoute table. As a first example, assume that PE node PEi receives a 
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multicast packet for group Gi. As an aside, note that in the current state of the art, there is 
no group identifier in an Ethernet packet, but rather, the mapping between 
source/ destination and group resides elsewhere, preferably in each PE node as may be 
achieved as known in the art With this information, and per the first routing entry in 
5 Table 1, PE node PEi transmits the packet to PE node PE5. As a second example, assume 
that PE node PEi receives a mxilticast packet for group G2. In this case, and per the second 
routing entry in Table 1, PE node PEi transmits the packet to two PE nodes, namely, PE2 
and PE3. Thus, if packet copies need to be sent to multiple PE nodes, then the next hop PE 
entry in the mRoute table will have multiple entries. As a third example, assxmie that PE 

10 node PEi receives a multicast packet for group Gi, but in this case assiune further that the 
source ingress PE node of tiie packet is PE node PE2, meaning PE node PE2 is the first PE 
node of network system 10 to route the packet along that system, so typically that would 
be the case where PE node PE2 received the packet from an adjacent core or access 
network. In other words, the packet entered or had ingress into network system 10, from 

15 another network (e.g., core or access), through PE node PE2. As a result, even though the 
subject packet is a group Gi packet which otherwise would be forwarded according to the 
first entry in Table 1, the combination of source and group is also specified in Table 1 in a 
source based tree entry (i.e., below the dashed line). In the preferred embodiment, when a 
soxirce base tree entry is satisfied in such a manner, then the soiurce based entry is used to 

20 determine the neixt hop rather than the general Steiner tree entry; in the present example, 
therefore, the packet is forwarded by PE node PEi to PE node PE4. 

[0025] For those instances where the mRoute table includes routing based on one or 
more source based trees, it is further recognized in connection with the preferred 
embodiments that by definition tiie source ingress PE node address of packets that will be 

25 routed by those trees must be discoverable by each PE node having a mRoute table. In 
this regard, the present state of the £irt for Ethernet packets and address learning does not 
provide such information. Thus, according to the preferred embodiments, an additional 
aspect is to provide a mechanism so as to provide the packet source information to each 
PE node in case it is needed by that node to route the packet Further in this regard, it is 

30 known in the art for each PE node to perform a process typically referred to as MAC 
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learning, which involves the communication of imicast traffic through network system 10. 
Generally, MAC learning provides connectivity information to a PE node that receives a 
packet, where the information identifies tiie transmitting node that commimicated that 
packet to the PE node; thus, the receiving PE node stores the connectivity information 
5 where thereafter the receiving PE node may then commimicate back to the transmitting 
PE node given that the receiving PE node previously stored, or 'leamed,'' that it is 
connected to the transmitting PE node. In the preferred embodiment, this learning 
methodology is extended so that a table may be created and maintained so as to assist 
with the use of the source based routes in the mRoute table, as further detailed below. 

10 [0026] Prior to discussing the additional learning methodology of the preferred 
embodiments, an understanding of certain aspects of the current state of the art for the 
format of an Ethernet packet (or "fi-ame") is beneficial. Toward this end. Figure 2 
illustrates a partial structure of a packet 20, where only certain fields of the packet are 
shown so as to simplify the discussion arid focus on various pertinent backgroimd. 

15 Looking to those fields, they include a payload field 20i, which includes the data that is 
intended for the ultimate recipient node. Adjacent payload field 20i is an extemal source 
address field 2O2 and an extemal destination address field 2O3. The term extemal is used in 
this doomient in connection with fieldis 2O2 and 2O3 to indicate that the addresses of those 
fields are typically extemal from the MEN that forms system 10. Ftirther, in an Ethernet 

20 context, both of these addresses are MAC addresses, so often the address of field 2O2 is 
referred to as a source MAC address and the address of field 2O2 is referred to as a 
destination MAC address. Also included in packet 20 is a type field 2O4. The type field 
specifies the type of packet that packet 20 presents, which may include with particular 
relevance to the preferred embodiments a tmicast type, a multicast type, or a broadcast 

25 type. Thus, those packets identified by field 2O4 as midticast packets may be treated 
consistent with the teachings in this docimient. Lastly, packet 20 includes a MEN source 
address field 2O5 and a MEN destination address field 206. These latter two addresses are 
the MAC addresses that apply to each P or PE node as the packet traverses through the 
MEN system 10. In other words, they are MEN-specific so that, in a given instance when 

30 packet 20 is being transmitted by one node P node or PE node in system 10, that node's 
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MAC address is included in the MEN somce address field lOs, and the destination node to 
which packet 20 is then being transmitted within MEN system 20 is included in ttie MEN 
destiiuition address field 206. Thus, as packet 20 traverses through system 10, these two 
fields will change with each hop based on the MAC addresses of the node that most 
5 recently transmitted the packet and the node to which packet 20 is being transmitted. 

[0027] Given the preceding, note that as packet 20 is received at system 10 and 
traverses through that system, there is no field in that packet that identifies the source 
ingress PE node of the packet, that is, the PE node that first received the packet in system 
10 from a node outside of that system. However, in the preferred embodiment, recall that 

10 the mRoute table requires knowledge of that source ingress PE node if the packet is to be 
routed according to a source based tree. Accordingly, also in the preferred embodiment, 
the unicast learning methodology described above is extended so that an association 
between MAC addresses external from system 10 are learned and associated with the 
address of the source ingress PE node that receives a cormntmication from that MAC 

15 address. In other words, returning briefly to Figure lb, assimie that PE node PEa receives 
a packet from a device, extemal from system 10, having a MAC address MACi. Thus, PE 
node PE2 stores this information in a table, so that thereafter there is a known association 
between MAC address MACi and PE node PE2. Each other PE node in system 10 operates 
in the same manner during the learning process and the totality of these types of 

20 associations are then distributed to all PE nodes in system 10 of the same type of group. 
Thus, for a PE node in a given group, its table of this sort may provide the mapping as 
shown in the following Table 2. 



External MAC address 


Source ingress PE node 


MACi 


PE2 


MAC2 


PE2 


MAC3 


PE4 


MAC4 


PE4 



Table 2 
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[0Q28] With the information in Table 2, and returning briefly to Table 1, one skilled in 
the art should appreciate how the mapping of the former facilitates routing according to 
the latter. Particularly, when a PE node receives a packet, and assuming the extended 
MAC learning associated with Table 2 has been previously performed, then the receiving 
PE node has knowledge of the MAC address from the source that originated the packet 
outside of system 10. Thus, if the ingress PE node associated with that MAC address is 
identified in the one or more source based trees of the mRoute table (e.g., below the 
dashed line in Table 1) and has a corresponding group indicated in that table, then the 
packet's next hop is determined from the mRoute table. For example, assume that a PE 
node using Tables 1 and 2 receives a packet with MAC address MACi and that packet is 
for distributing to group Gi. From Table 2, MAC address MACi is associated with PE 
node PE2. Further, per Table 2, a group Gi packet that entered system 10 by way of ingress 
to PE node PE2 is to be transmitted to PE node PE4; thus, the example packet is so 
transmitted. 

[0029] From the above illustrations and description, one skilled in the art should 
appreciate that the preferred embodiments provide a computer network that supports a 
combined multicast and xmicast architecture, which is preferably embodied in a virtual 
private local area network service in a metro Ethemet network. The preferred 
embodiments provide variotis benefits in supporting both unicast and midticast 
commxmications. For exeimple, the preferred embodiment allows for optimization of the 
t5P resources for multicast traflEic. As another example, no new LSP(s) is/ are needed to 
accommodate multicast comniunicaitions beyond those used for unicast communications. 
As another example, the preferred embodiments provide dynamic, centralized solution. 
Further, the determination of the multicast tree(s) can be done at periodic intervals, or 
when there is a new multicast group added to the network. As a final benefit, while the 
present embodiments have been described in detail, various substitutions, modifications 
or alterations could be made to the descriptions set forth above without departing froin 
the inventive scope which is defined by the following claims. 
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